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Many programs and libraries involve components that are ‘function-like’, in that 
they take inputs and produce outputs, but are not simple functions from inputs 
to outputs. This chapter explores the features of such ‘notions of computation’, 
defining a common interface, called ‘arrows’. This allows all these notions of com- 
putation to share infrastructure, such as libraries, proofs or language support. 
Arrows also provide a useful discipline for structuring many programs, and allow 
one to program at a greater level of generality. Monads, discussed in Chapter 11 
of IFPH, serve a similar purpose, but arrows are more general. In particular, they 
include notions of computation with static components, independent of the input, 
as well as computations that consume multiple inputs. We also consider some use- 
ful subclasses of arrows, one of which turns out to be equivalent to monads. The 
others bring choice and feedback to the arrow world. 

With this machinery, we can give a common structure to programs based on 
different notions of computation. The generality of arrows tends to force one into 
a point-free style, which is useful for proving general properties. However it is not 
to everyone’s taste, and can be awkward for programming specific instances. The 
solution is a point-wise notation for arrows, which is automatically translated to 
the functional language Haskell. Each notion of computation thus defines a special 
sublanguage of Haskell. 

1 Notions of computation 

We shall explore what we mean by a notion of computation using four varied 
examples. As a point of comparison, we shall consider how the following operator 
on functions may be generalized to the various types of ‘function-like’ components. 


add :: ((3 —>■ Int ) — > (/3 — > Ini) — > (/3 — > Ini) 
add f g b = f b + g b 


State transformers: Applications that involve the threading of a state through a 
function might have types described by 
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type State <r i o = (cr, c) —>■ (a, o ) 

A generalization of add to state transformers is 

addST :: State a (3 Int — t State a P Int — t State cr P Int 

addST f g (s, 6) = let (s', x) = f (s, b) 

(s",y) = g (s', b) 
in (s",x + y) 

which we can picture as below: 



But for the clotted line, this is the same as add. The difference is that the state a 
is threaded first through / and then through g to produce the resulting state. This 
is not the only choice: we could have defined addST to thread the state through g 
and then through /. 

Nondeterminism: Many search algorithms may be described as functions that re- 
turn a list of possible answers (with the empty list indicating failure): 

type NonDet io = i — >• [o] 

The generalization of add is to add each combination: 

addND :: NonDet p Int — > NonDet P Int — > NonDet p Int 
addND fgb=[x + y\x <- f b, y < - g b\ 

The effect under lazy evaluation is similar to backtracking. To compute the head 
of the list, the function gets the first elements from / and g. To compute the next 
element, it gets the next element from g if any, or otherwise the next element from 
/ and the first from g , and so on. As with state transformers, another version is 
available: we could have gone through all the results of / first. 

More sophisticated variations on this idea are discussed in Chapter ??. 

Map transformers: A data parallel algorithm transforms a family of input values, 
one for each place in a set (J. into a family of output values at the same places: 

type MapTrans a i o = (a — > l) — > (a — > o) 

Another interpretation takes er as representing time, so that a function a — >• a is 
a time- varying value, or behaviour , and the component is a behaviour transformer. 
The generalization of add to map transformers adds the functions pointwise: 

addMT :: MapTrans cr p Int -A- MapTrans a p Int — > MapTrans a p Int 
addMT f g m s = / m s + g m s 
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If <7 represents place, this corresponds to evaluating / and g at each place and 
summing each pair of results. If a represents time, this operator adds the values 
of two behaviours at each point in time. 

Simple automata: One way to model synchronous circuits is to use simple au- 
tomata, which map an input to an output and a new version of themselves: 

newtype Auto i o = A (l — » (o, Auto l o)) 

The generalization of add to automata runs the two automata in parallel, summing 
each pair of results: 

addAuto :: Auto p Int — t Auto P Int — >• Auto P Int 

addAuto ( Af ) (A g) = A (X b let (x,f) = f b 

(y,g') = gb 

in (x + y, addAuto f g')) 


1.1 Categories and functors 

In each of the above examples, and many more like them, there is a type A ^ B 
of computations taking inputs of type A and producing outputs of type B. It 
is natural to ask what else these examples have in common. We shall define an 
interface that is sufficiently general to encompass our examples (and many others), 
but also powerful enough to program general combinators like add. 

It seems reasonable to expect that we can compose two computations by con- 
necting the output of the first to the input of the second, and that composition 
is associative with an identity (a ‘do-nothing’ computation). This is the standard 
notion of a category, with types as objects and computations as arrows (or mor- 
plrisms). We can represent this in Haskell with the class 

class Category a where 
id A :: a p P 

(^>) :: a P 7 — > a-y 5 — > a P 5 

Haskell does not permit infix type constructors like so the arrow type construc- 
tor a is placed before its two type arguments. 

In a category, these operations are required to satisfy the axioms 

identity idA f = / idA = f 

associativity (/ ^ g) h = f {g h) 

Pure functions constitute a category: 

instance Category (—>) where 
idA = id 
f ^ g = g ■ f 
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A category is a very general concept, and it is perhaps no surprise that all of our 
examples induce categories, as do many other things. However this interface is 
much too general (or offers too little) for programming purposes. Firstly, we shall 
also require a combinator to embed ordinary functions as ‘pure’ computations: 

pure :: (ft — > 7) — > a ft 7 

satisfying the following axioms: 

functor-identity pure id = idA 

functor-composition pure (g ■ f) = pure f pure g 

Normally functional programmers use only functors, like map, from the category 
of functions to itself, but pure is a functor from the category of pure functions to 
the new category. 

Using pure, we can lift functions like + to computations, but this is still not 
enough to implement a generalization of add. So far, the results of a computation 
must be fed to the immediately following computation; we have no way to save 
intermediate results. We need a means to apply a computation to part of the 
input, while preserving the rest. In the category of functions, this is done using 
the product functor : 1 

(x) :: (a — > a') — > (ft — > ft') —> {a, f3) — > (a 1 , ft') 

(/ x 9)~(a, b) = {f a, g b) 

The operator x is a functor in two arguments, so that we have 

(/ ' 9) x [h ■ k) = (/ xh)-(gxk) 

This does not generalize directly to other notions of computation. For example, in 
state transformer computations the order of g and h cannot be changed without 
changing the effect of the computation. However, it suffices to assume a one-sided 
product, which we shall call first. Hence instead of Category, we use the following 
class: 

class Arrow a where 

pure :: (ft — > 7) — > a /3 7 
(^> ) :: a ft 7 — > 07 6 — > a ft 6 
first :: a ft 7 a (ft, S) (7, 6) 

There is no need to assume idA, because it is uniquely defined by the functor- 
identity law for pure: 

idA :: Arrow a => a ft ft 
idA = pure id 

We need not assume a mirror image of first, as it may be defined as 

1 The tilde marks an irrefutable pattern in Haskell. It is used in this and some later definitions 
to make the matching of pairs non-strict. 
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second :: Arrow a => a f3 7 — > a (5, (3) (5, 7) 
second f = pure swap first f pure swap 
where swap ~(x, y) = (y, x) 

We assume that first satisfies the following axioms: 

extension first (pure /) = pure (f x id) 

functor first (f g) = first f first g 

exchange first f pure (id x g) = pure (id x g) first f 

unit first f pure fst = pure fst / 

association first (first f) pwre assoc = pure assoc first f 

where assoc rearranges pairs: 

assoc :: ((a,/3),y) -t (a,(0,y)) 

assoc ~(~(a, b), c) = ( a,(b , c)) 

Ordinary functions are an instance of the Arrow class: 

instance Arrow (— >) where 

pure f =f 

f ^ 9 = 9 ■ f 
first f = / X id 

Our other examples are also instances, though in some cases we must alter the 
definitions slightly, because Haskell does not permit type synonyms as instances: 

newtype State a 1 o = ST ((cr, l) — > (a, 0)) 

newtype NonDet 10 = ND (l — > [o]) 

newtype MapTrans a l 0 = MT ((a — t t) — t (a — t o )) 

Now we can define an instance for the State type. A pure state transformer leaves 
the state untouched, while first routes the state through /: 

instance Arrow (State a) where 
pure f = ST (id x /) 

STf » ST g = ST (g ■ /) 

first (ST /) = ST (assoc ■ (f x id) ■ unassoc) 

where unassoc is the inverse of assoc: 

unassoc :: (a, (/?, 7)) — > ((a,/3), 7) 

unassoc ~(a, ~(b, c)) = ((a, b), c) 

A pure non-deterministic computation is a single-valued, or deterministic, compu- 
tation, while composition encapsulates backtracking: 

instance Arrow NonDet where 
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pure f = ND (A b — > [ f &]) 

ND f ND g = ND (A b ->■ [d \ c <- f b, d <- g c\) 
first {ND f) = ND (A {b, d) — >• [(c, d) \ c -s- / 6]) 

A pure map transformer applies a function to each result of the map, while first 
applies a transformer to only part of a map: 

instance Arrow {MapTrcins a) where 
pure f = MT (/ •) 

MTf MT g = MT {g ■ f) 

first {MT f) = MT {zipMap ■ (/ x id) ■ unzipMap ) 

where zipMap and its inverse unzipMap convert between pairs of maps and maps 
yielding pairs: 

zipMap :: {a — > a, a — > / 3 ) — > {a — > (a,/?)) 
zipMap h s = {fst h s, snd h s) 

unzipMap :: {a — >• (a, /?)) — » {a — > a, a — >• ( 3 ) 
unzipMap h = {fst ■ h, snd ■ h) 

The instance for automata is a bit more complicated: 

instance Arrow Auto where 

pure f = A (A b — >• ( fb,puref )) 

Af A g = A (A b -t let {c,f) = f b 

{d,g') = g c 
in {d, f g')) 

first {A f) = A (A (b, d) -t let {c,f) = f b 

in ((c, d), first /')) 

Remember that an automaton maps an input to an output and a new version of 
itself to be used on the next input. In the case of a pure automaton, the new 
version is the same as the old one: the automaton is stateless, with each output a 
function of the corresponding input. A pair of automata are composed by running 
them side by side, with each output of the first used as an input to the second. 

Now we can write some general combinators for arrows. For example, we can 
define something that looks like a product: 

(**) :: Arrow a => aft 7 — > aft' 7' — > a {ft, ft') (7, 7') 

f m g = first f second g 

Note that we have arbitrarily chosen an order for the computations / and g. For 
many arrows {e.g. state transformers), the other order has a different meaning. As 
a consequence, m is not in general a functor. 

A convenient variant duplicates the input first: 

(&&fc) :: Arrow a => aft 7 — > a ft 7' — > a ft (7, 7') 

/ &fcfc g = pure dup (/ * g) 
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where dup b = ( b,b ) 

A general combinator corresponding to add is: 

addA :: Arrow a => a [3 Int — > a (3 Int — > a (3 Int 
addAf g=f &&fc g pure (uncurry (+)) 

Each of the versions of add defined above may be obtained by specializing addA 
with the appropriate arrow type. 

Exercise 1 Write Arrow instances for the following types: 

newtype Reader a i o = R ((<r, t) — » o) 
newtype Writer to = W (i — > ( String , o)) 

In the latter case, any monoid could be used in place of String. □ 

Exercise 2 The following is almost an arrow type: 

newtype ListMap t o = LM ([i] [o]) 

What goes wrong? □ 

Exercise 3 Define the following as an arrow type: 

data Stream a = Cons a ( Stream a) 

newtype StreamMap t o = SM ( Stream t — >• Stream o) 

This enables us to mimic dataflow languages, in which an infinite list represents all 
the values of a variable, or Kahn networks, in which a list represents all the values 
that pass through a channel. □ 

Exercise 4 Show that the following is a functor: 

(k) :: Arrow a =4> a (3 7 — » (/?' — > 7 ') — > a (/3, /3') ( 7 , 7 ') 

/ ix g= first f {id x g) 


□ 

2 Special cases 

We consider here a number of interfaces that are less general than arrows, but 
which nevertheless offer useful additional facilities when available. 

2.1 Arrows and monads 

The Arrow combinators operate on computations, rather than the values that pass 
through them. They are point-free , in contrast to normal functional programming, 
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where we use named values (variables) bound by A or let. We could name inputs 
to arrows in the same way if the arrow type a satisfied 

currying a {$,')) 8 = f3 — » a 7 8 

(This is an example of what category theorists call an adjunction.) There is a 
obvious function from the left side to the right: 

curry A :: Arrow a =>■ a ((3,"/) 8 — > /3 — > a 7 8 

curry A f b = mkPair b / 

mkPair :: Arrow a =>■ /3 — >• a 7(^,7) 
mkPair b = pure (Ac -> (6, c)) 

But does curry A have an inverse? Such an inverse would map id :: a j 8 — » a j 8 
to a combinator 

class Arrow a => Arrow Apply a where 
app :: a (ct 7 8, 7) 8 

Indeed, it can be shown that a natural currying isomorphism exists if and only if 
such an arrow app exists and satisfies the axioms: 

composition pure ((^> h) x id) app = app h 

reduction pure ( mkPair x id) app = pure id 

extensionality mkPair f app = / 

Pure functions are a trivial instance of this class: 

instance ArrowApply (— >•) where 
app'if , c)=fc 

Of the other arrows we have considered, State and NonDet are instances, but 
Map Trans and Auto are not. Indeed, the currying isomorphism implies 

a j3 8 = a(/3,Q)8 = /3 — > a () 8 

and any such arrow may be factored as /3 — > MS, where M is a monad. Conversely 
any monad gives rise to an arrow of this form, called its Kleisli arrow, which satisfies 
the currying isomorphism. Thus the ArrowApply class is merely a less convenient 
version of the Monad class. It describes computations that always take a single 
input. However, arrows also include computations that consume multiple input 
values (like MapTrans and Auto), as well as computations that are partially static, 
i.e. independent of the input. We shall see examples of both kinds in Section 4. 

Exercise 5 Verify the ArrowApply axioms for pure functions. □ 

Exercise 6 The following instance has the correct type: 
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instance ArrowApply Auto where 

app = pure (A (A /, x) fst (/ x)) 

Show that the extensionality axiom fails for this definition. □ 

2.2 Conditionals 

In many situations we wish to perform different computations for different inputs. 
This would be trivial if we could refer to the input directly, as with monadic 
computations (or, equivalently, ArrowApply). Although this is not available for 
arrows in general, more arrows admit conditional computation than currying. We 
begin with a Haskell sum type: 

data Either a [3 = Left a \ Right 

Just as with the product type, there is a corresponding functor: 

(©) :: (a a') — »• (/3 — »• /?') — > Either a (3 Either a' f3' 

{} © 9) {Left a) = Left (/ a) 
if © g) {Right, b) = Right {g b) 

By analogy with products, we postulate a one-sided sum functor on arrows: 

class Arrow a => ArrowChoice a where 

left :: a /3 7 — > a ( Either (3 S) ( Either 7 8) 

As with products, the mirror image may be defined: 

right :: ArrowChoice a => a f3 7 — >• a {Either 8 (3) {Either S 7) 
right f = pure mirror left f ~^> pure mirror 
where mirror {Left x ) = Right x 
mirror ( Right y) = Left y 

The axioms for left mirror those for first: 

extension left {pure f) 

functor left (/ g) 

exchange left f pure {id, © g) 

unit pure Left left f 

association left {left f) pure assocsum 

for the function 

assocsum :: Either {Either a (3) 7 — >• Either a {Either (3 7) 

assocsum {Left {Left a)) = Left a 
assocsum ( Left {Right, b)) = Right {Left b) 
assocsum ( Right, c) = Right {Right c) 


= pure (/ © id) 

= left f left g 

= pure {id © g) left, f 

= f pure Left 

= pure assocsum left f 
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In the world of pure functions, sums and products are related by the function 

distr :: {Either a ft, 7) —> Either {a, 7) {ft,"/) 

distr { Left a, c) = Left (a, c) 
distr { Right b, c ) = Right {b, c) 

We also postulate an additional axiom for arrows: 

distribution first {left f) pure distr = pure distr left {first /) 

We can define derived combinators corresponding to those for products: 

(<$>) :: Arrow Choice a => 

aft"/ — > aft'"/' — t ct {Either ft ft’) {Either 7 7') 

/ <©> g = left f np/it g 

(HI) :: Arrow Choice a => a ft 6 a "/ 6 — >• a {Either ft 7) 6 

/ 1 1 1 5 = / 0 > 5 pure untag 

where untag {Left x) = x 
untag {Right y) = y 

Naturally pure functions are an instance of ArrowChoice: 
instance ArrowChoice (— ») where 

left f = f © id, 

Indeed any instance of Arrow Apply , including State and NonDet , is also an instance 
of ArrowChoice. More interestingly, simple automata allow choice, even though 
they do not permit application: 

instance ArrowChoice Auto where 

left {Af) = A If 

where If {Left b ) = let {c,f') = f b 

in {Left c, left /') 

If {Right d) = {Right d , left {A /)) 

Only inputs marked Left are run through the automaton, while others are copied 
to the output. 

There is no ArrowChoice instance for map transformers. 

Exercise 7 Define ArrowChoice instances for NonDet , State and the StreamMap 
type from Exercise 3. □ 

Exercise 8 Show that the equation 

(/ (I] g) ;g> h = (/ h) HI {g h) 

fails for the Auto and StreamMap arrows. □ 
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Exercise 9 Given the following definition, which adds string-valued exceptions to 
an arrow: 

newtype Except a (3 7 = E (a (3 ( Either String 7)) 

Define the following instance 

instance ArrowChoice a => Arrow ( Except a) 

□ 

Exercise 10 Prove the functor axiom for first in the arrow defined in the previous 
exercise. This requires the distributivity axiom. □ 

2.3 Feedback 

Since arrows are Haskell values, they may be recursively defined in the usual way. 
Sometimes we want a different form of recursion, where values input to an arrow 
are defined in terms of its outputs, as in the following diagram: 

1 

1 7 

/ I * 

I 

I 

I 

6 

J 

For ordinary functions, we can define a function category theorists call a trace: 

trace :: ({(3,6) — 1 (7, 5)) — > (3 — > 7 
trace f b = let (c, d) = f (b, d) in c 

Here the second component of the output of / is fed back as the second component 
of its input. Some arrows permit a generalization of trace, characterized by the 
class 

class Arrow a => ArrowLoop a where 
loop :: a ((3,5) (7, 6) — 1 a (3 7 

The intention is that while the value is fed back, any effect of the computation 
occurs once only, and this is reflected by the axioms of loop: 

extension loop (pure f) = pure (trace f) 

left tightening loop (first h f) = h loop f 

right tightening loop (f first h) = loop f h 

sliding loop (/ pure (id x k)) = loop ( pure (id x k) /) 

vanishing loop (loop f) = 

loop ( pure unassoc f pure assoc) 
superposing second (loop f) = 

loop ( pure assoc second f pure unassoc ) 



L 
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For example, a computation that is independent of the feedback value may be 
moved out of the loop , as in the ‘tightening’ axioms. 

As we have already seen, ordinary functions support such an operator: 

instance ArrowLoop (— ») where 
loop = trace 


In the case of state transformers, we want a function that transforms the state 
once, while feeding back part of the output: 




i a 


/ 

i ► 

i 


-i : 7 


L 

i 


6 

i 

i 


We can implement this directly, with a little manipulation of the pairs: 

instance ArrowLoop ( State a) where 

loop (ST f) = ST ( trace (unassoc ■ f ■ assoc)) 

This definition is almost an inside-out version of the definition of fi,7'st for state 
transformers. The instance for map transformers is similar: 

instance ArrowLoop (Map Trans a) where 

loop (MT f) = MT (trace (unzipMap ■ f ■ zipMap)) 

The instance for automata is more subtle. At each stage, part of the output is fed 
back to the input: 

instance ArrowLoop Auto where 

loop (A f) = A (X b -i let (~(c, d),f) = / ( b , d) 
in (c, loop /')) 

However there is no loop operator for non-deterministic functions, unless we are 
prepared to relax our axioms. 

Exercise 11 Define an ArrowLoop instance for the StreamMap type from Exer- 
cise 3. □ 

Exercise 12 Prove that loop (first f) = f . □ 

3 Arrow notation 

Arrows present a usefully general interface to computation, but we have seen that 
they force a point-free style. This may be convenient for general definitions and 
Minor rephrasing to irn- proofs, but it can be cumbersome for specific programming. For example, suppose 
prove pagebreaks 
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we have the following operations for the state transformer arrow: 

fetch :: State a () er 

fetch = ST (A(s, ()) ->• (s,s)) 

store :: State a a () 

store = ST (A (s, s') — > (s', ())) 

The following arrow uses an integer state to generate a fresh number: 
genSym :: State Int () Int 

genSym = fetch pure incr first store pure snd 
where incr n = (n + l,n) 

Note that we must explicitly describe the plumbing, duplicating the n, passing the 
new value to store and then discarding its result. 

To facilitate programming with arrows, we extend the Haskell syntax with a 
new sort of expression, the proc expression for defining arrows. Here is a version 
of genSym in the new notation: 

genSym :: State Int () Int 
genSym = proc () — » do 

n <— fetch — < () 
store — < n + 1 
idA — < n 

The right-hand side is a proc expression, a variation on a lambda expression that 
defines an arrow. In this case the input has the form (). The next line passes a 
value () through the arrow fetch, naming the result n. (The — < symbol is meant 
to signify an arrow tail.) The value n + 1 is then sent to store. Finally n is sent 
to the identity arrow idA to produce the output of the whole arrow. 

The new expressions are defined by the grammar of Figure 1. A command 
occurs as the body of a proc binding, and elsewhere. It returns a value, but may 
also have some effect. The simplest sort of command is built using the arrow tail 
— < which acts as a sort of application of an arrow to an input expression. The 
above example includes sub-commands fetch — < () and store n + 1 that are 
of this form. The do command consists of a series of statements, which may define 
variables or simply execute commands for effect, followed by a final command, in 
the above example idA — < n. 

These new forms are given meaning by translation to ordinary Haskell, using 
the rules of Figure 2. Note in particular the two translations for arrow application 
(— <). The first is syntactically restricted, but is valid for any arrow. In the special 
case where / is idA, we have 

proc p — > do idA — < e = pure (A p — > e) 

The second possibility has no such syntactic restriction, but because its translation 
uses app, the arrow in the type of the arrow expression must be an instance of the 
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exp 

— ■ ■ ■ 



proc pat — > cmd 

cmd 

= exp — < exp 



do { stmt ; . . 

. ; stmt; cmd } 

stmt 

= pat <r- cmd 



cmd 



rec { stmt; . . 

. ; stmt } 


Figure 1: Grammar for arrow expressions 


( pure (Xp — »• a) ^ / if FV{p) D FV(f) = 0 
proc p — ► f — < a = < 

( pure (Xp — > (/, a)) app otherwise 

proc p — > do { c } = proc p — > c 

proc p — > do { p' 4— c; B } = ((proc p — > c) idA) 

proc (p',p) — > do { B } 

proc p — > do { c; B } = proc p — > do { _ <r- c; B } 

proc p — > do { rec { A }; B} = 

idA &&&: loop (proc ( p,pa ) - A - do { A; idA — < (pb,Pa) }) ^ 
proc (p,p B ) -> do { B } 

Figure 2: Translation rules for arrow expressions 


ArrowApply class. Thus neither form is more general than the other, and both are 
useful. 

The third rule deals with binding of new variables. As the translation makes 
clear, a copy of the original input (described by p) must be routed around the 
command c for use in the rest of the do command, which also has access to the 
output of c, bound by p' . The next rule is the special case where we wish to discard 
the output of a command, as with store in the genSym example. 

The last rule, dealing with recursion, is more involved. The right side may be 
visualized as follows: 
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Figure 3: A resettable counter circuit 



Here pA is a pattern containing all the variables that are both defined and used in 
A. while the pattern pB contains the variables defined in A that are used in B. Note 
that if recursion is used, the arrow involved must be an instance of ArrowLoop . 

Exercise 13 Use the rules of Figure 2 to translate the above definition of genSym 
into ordinary Haskell, and use the axioms to simplify the result. Compare your 
answer with the point-free version. □ 

Exercise 14 Prove that when both translations of proc p — > / a are possible, 
they are equal. □ 

Exercise 15 Suppose the syntax is extended with a new form of command 
if exp then cmd else cmd 

Suggest a translation for the new form, assuming the arrow concerned belongs to 
ArrowChoice. A case command could be defined similarly. □ 


4 Examples 

4.1 Synchronous circuits 

A synchronous circuit receives an input and produces an output on each tick of 
some global clock. The output for a given tick may depend on the input for that 
tick, as well as previous inputs. Consider the simple circuit of Figure 3 (taken 
from [13]). This circuit represents a resettable counter, taking a Boolean input and 
producing an integer output, which will be the number of clock ticks since the input 








16 


Arrows and computation 


was last True. To achieve this, the output is incremented and fed back, delayed by 
one clock cycle. The first output of the DELAY component is its argument, here 0; 
its second output is its first input, and so on. 

We propose to treat circuits as arrows. It suffices to consider circuits with 
a single input and output, because multiple inputs may be treated as input of a 
tuple, and similarly for output. 

• The pure operation defines circuits where each output is a pure function of 
the corresponding input ( e.g . IF and +1 in the above circuit). 

• Composition connects the output of the first circuit to the input of the second. 

• The first operation channels part of the input to a subcircuit, with the rest 
copied directly to the output. 

As with any arrow instance, we shall require additional operations. We define 
circuits as arrows that support cycles and a delay arrow: 

class ArrowLoop a =>■ ArrowCircuit a where 
delay :: /? — > a (5 j 3 

The argument supplies the initial output; subsequent outputs are copied from the 
input of the previous tick. A circuit built with loop will not work unless it includes 
a delay somewhere on its second input before using it, as in the example above. 
One could enforce this by combining the two in a single construct, but the present 
formulation is better suited to algebraic manipulation. 

Here is the resettable counter circuit in arrow notation: 

counter :: ArrowCircuit a =7 a Bool Int 
counter = proc reset — > do 

rec output idA if reset then 0 else next 
next <— delay 0 output + 1 
idA output 

This corresponds rather directly to the graphical presentation of Figure 3. The 
variables denote the values passing through wires on a particular clock tick. 

Several implementations of the ArrowCircuit class are possible, allowing many 
different interpretations of circuit descriptions. For example, we already have an 
ArrowLoop instance for simple automata, so we need only implement delay: 

instance ArrowCircuit Auto where 
delay b = A (A b 1 (6, delay b')) 

To simulate a circuit, we feed it a list of inputs, extracting a list of the same number 
of outputs: 

runAuto :: Auto ft 7 — >• [ft\ — >• [7] 

runAuto (A f) [\ = [] 

runAuto (Af)(b: bs) = let (c,f) = f bin (c : runAuto f bs) 
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However many other other arrows satisfy the ArrowCircuit interface, permitting a 
range of interpretations of a single circuit description. An interpretation could add 
probes that show intermediate values, or calculate static properties of a circuit, 
such as a wiring description. 

Exercise 16 Define an ArrowCircuit instance for the StreamMap type from Exer- 
cise 3. □ 

4.2 Homogeneous functions 

Many parallel algorithms and circuit designs operate on collections of 2" elements, 
with behaviour defined by induction on n. We can model these collections in 
Haskell using the following type: 

data BalTree a = Zero a | Succ ( BalTree ( Pair a)) 
type Pair a = ( a , a) 

Here are some example elements: 

treeO = Zero 1 

tree 1 = Succ ( Zero (1,2)) 

tree 2 = Succ ( Succ ( Zero ((1,2), (3,4)))) 

tree3 = Succ ( Succ (Succ ( Zero (((1, 2), (3, 4)), ((5, 6), (7, 8)))))) 

The elements of this type have a string of constructors expressing a depth n as a 
Peano numeral, enclosing a nested pair tree of 2" elements. However few algorithms 
can be expressed in terms of the balanced tree type. Typically one wants to split a 
tree into two subtrees, do some processing on the subtrees and combine the results. 
But the type system cannot discover that the two results are of the same depth 
(and thus combinable). 

The solution is to define a type we call homogeneous functions , namely families 
of functions mapping trees of size 2" to trees of the same size 2": 

data Horn a (3 = (a —> j3) :&: Horn (Pair a) (Pair (3) 

Elements of this type have the form 

/ o :&: A :&:/ 2 :&:... 

where f„ :: Pair n a — » Pair n (3. 

The following function applies a homogeneous function to a perfectly balanced 
tree, yielding another perfectly balanced tree of the same depth: 

apply :: Horn a (3 — >• BalTree a — >• BalTree f3 

apply (f :&: fs) (Zero x ) = Zero (f x ) 
apply (f :&: fs) (Succ t ) = Succ (apply fs t) 

Having defined apply, we can program with the Horn type and forget about BalTree. 
Firstly, Horn is an arrow: 
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instance Arrow Horn where 

pure f -■ f pure (/ x /) 

(/ fs) ( g gs) = {g ■ /) (fs gs) 
first (/ /s) = 

(/ x id) (pure transpose first fs pure transpose ) 


transpose :: ((a, /3), (7, d)) -> ((a, 7), (/3, d)) 

transpose ((a, b), (c, d)) = ((a, c), (6, d)) 

The function pwre maps a function over the leaves of the tree. The composition 
composes sequences of functions pairwise. The m operator unrifhes a tree of 
pairs (a, /?) into a tree of as and a tree of /3s, applies the appropriate function to 
each tree and riffles the results. 

When describing algorithms, one often provides a pure function for the base 
case (trees of one element) and an expression for trees of pairs, usually invoking 
the same algorithm on smaller trees. 

Parallel Prefix: This operation (also called scan) maps the sequence 

X\ , X2 5 X3 , . . . , X 2 n 

to the sequence 

Xi, X\ + X2, X\ + X2 + X3, . . . , Xi + X 2 + ■ ■ ■ + X2n 

(All this generalizes easily from + to any associative operation.) 

If there is only one element ( i.e . the tree has zero depth) then obviously the 
scan should be the identity function. Otherwise, we need to deal with a tree of 
pairs, so the general scan operation will have the form 

scan :: Num j3 =$■ Horn f3 j3 

scan = id proc (x, y) — > (something using scan on smaller trees) 

An efficient scheme, devised by Ladner and Fischer [12], is first to sum the elements 
pairwise: 


Xi + X 2 , x 3 + x 4 , x 5 + *6, • • • 

and then to compute the scan of this list (which is half the length of the original) , 
yielding 

X\ + X2, X\ + X2 + X 3 + X4, Xi + X 2 + X 3 + X4 + X 5 + Xq, ... 

This list is half of the desired answer; the other elements are 

Xi, Xi + X2 + X 3 , Xi + X2 + x 3 + X4 + x 5 , ... 

which can be obtained by shifting our partial answer one place to the right and 
adding X\ . x 3 , x 3 , ... . We can express this idea directly in our notation: 
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scan :: Num fl => Horn [3 j3 
scan = id proc (o, e) — >• do 

e' scan — < o + e 
ei rsh 0 — K e' 
idA — < (el + o, e') 

The auxiliary arrow rs/i b shifts each element in the tree one place to the right, 
placing b in the now-vacant leftmost position, and discarding the old rightmost 
element. This could be supplied as a primitive, but it is also possible to code it 
directly: 

rsh ::/?—>■ Horn (3 f3 
rsh v = const v proc (o, e) — > do 
o' 4— rsh v — < e 
idA — < (o', o) 

Butterfly Circuits: In many divide-and-conquer schemes, one recursive call pro- 
cesses the odd-numbered elements and the other the even ones [9]: deleted second ‘pro- 

cesses’ to avoid bad 

butterfly :: (Pair fl -»• Pair f) Horn f (3 linebreak 

butterfly f = id proc ( o , e) — >• do 

o' 4— butterfly f o 
e! 4— butterfly f — < e 
idA — < / (o', e') 

The recursive calls operate on halves of the original tree, so the recursion is well- 
defined. (The Fast Fourier Transform has a similar structure. See also Chapter ?? 
for another view.) Here are some examples of butterflies: 

rev :: Horn (3 [3 
rev = butterfly swap 

unriffte :: Horn (Pair (3) (Pair f3 ) 

unriffle = butterfly transpose 

Batcher’s ingenious sorter for bitonic sequences [1] is another example of a butterfly 
circuit: 

bisort :: Ord f3 =>■ Horn (3 f3 
bisort = butterfly cmp 

where cmp (x, y) = (min x y, max x y) 


Exercise 17 Use the functions defined in this section to define an arrow 
sort :: Ord [3 =>■ Horn (3 (3 

using a merge based on Batcher’s bitonic sorter, combined with rev. □ 
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4.3 Combining arrows 

We have seen that each arrow type embodies a notion of computation. Sometimes 
we want to combine two such notions, e.g. dataflow with state. The trick is to 
generalize one of the arrows to an arrow transformer , and then apply it to the 
other one. For example, state transformers were defined using functions, but we 
can generalize to any arrow: 

newtype StateT a a i o = ST ( a (a, i) ( a , o)) 

Now we can define a new arrow for each arrow a, as follows: 

instance Arrow a =>■ Arrow ( StateT a a) where 

pure f = ST (proc (s, b) — > idA —< (s,f b)) 

ST f ^ ST g = ST (f ^ g) 
first (ST /) = ST (proc (s, (b, d)) — > do 

(s', c) -«— / — < (s, b) 
idA — < (s', (c, d))) 

The arrow notation is useful here, especially in the definition of first. Now State 
may be defined as a special case: 

type State a = StateT a (— >•) 

The transformer StateT could be also applied to Auto, yielding an automaton that 
also transforms a state on each iteration. 

Arrows can also model static data, which is independent of the input. For 
example, the following arrow transformer augments an arrow with an integer count: 


data Count a i o = Count Int ( a i o) 

The arrow combinators of the base arrow lift directly to the new arrow: 

instance Arrow a => Arrow (Count a) where 

pure f = Count 0 ( pure /) 

Count nl f 1 Count n2 f 2 = Count (nl + n2) (/I /2) 

first ( Count n f) = Count n (first /) 

Other arrow combinators lift similarly: 

instance ArrowChoice a => ArrowChoice ( Count a) where 
left ( Count n /) = Count n (left f) 

This is a very simple example, but the ability to handle such static information 
enables arrows to express many efficient algorithms. An example is parser com- 
binators that compute properties of the grammar, independent of the input being 
parsed [17]. 
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Exercise 18 Rewrite the definition of StateT without arrow notation. □ 
Exercise 19 Given the following definition, 

newtype AutoFunctor a l o = A {a l (o, AutoFunctor a t o)) 
write the following instance, using arrow notation (or not): 
instance Arrow a Arrow ( AutoFunctor a) 


□ 

5 Chapter notes 

Arrows were invented as a programming abstraction by John Hughes [8], to deal 
with libraries that did not fit the monad model. Unknown to Hughes, workers 
in denotational semantics had also defined generalizations of monads, based on 
premonoidal categories [16]. A special case of these structures, later called a Freyd- 
category, turns out to be identical to Hughes’s definition. 

Hughes also introduced the ArrowApply and ArrowChoice classes, though the 
distribution axiom is new here. The ArrowLoop class [15] generalizes traces, de- 
fined by Joyal, Street and Verity [11], and the recursive monads of Erkok and 
Launchbury [7]. A more primitive and powerful version of the arrow notation 
sketched here may also be found in [15]. More information about arrows, includ- 
ing a preprocessor implementation this notation, may be found on the web page 
http : //www . haskell . org/arrows/. 

The embedded language FRP [6], used to model reactive situations such as 
robotics and graphical interfaces, has recently been reformulated in terms of ar- 
rows [5]. Map transformers are used as the abstract semantics, though implemen- 
tations use variants of stream maps or automata. 

Several dataflow languages have been used to model circuits [2, 4, 18]. The 
microarchitecture design language Hawk [13] abstracts over the type of values that 
may pass through wires. Low-level descriptions deal with bits (Bool), but any 
Haskell type may be used, allowing Hawk to scale to much more abstract descrip- 
tions, and also allowing the same circuit description to be simulated or symbolically 
executed. Related ideas are discussed in Chapter ??. There, circuits are functions, 
but in another version of the hardware description language Lava [3] , circuits have 
the form Value — > Monad Value' where both value and monad types are param- 
eters described by Haskell classes. By selecting appropriate instances, a single 
description may be simulated, symbolically executed or presented in a variety of 
styles. 

Formalisms related to our homogeneous functions include Ruby [10], used in 
circuit design, and Misra’s powerlists [14]. 

Hughes [8] also introduced arrow transformers, including the state arrow trans- 
former. 
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